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Beschreibung 1 9. ^^Z. 2003 

Verfahren zur Vergebiihrung eines Dienstes in einem Kommunika 
tionsnetz 

Problemstellung der Erfindung 



In einem paketorientierten Kommunikationsnetz mit Dienstan- 
wendern (z.B. SIP-Clients) , Diensterbringern (z.B. Applikati- 

10 ons-Servern) und einem vermittelnden Applikationsbroker (z.B, 
SIP Proxy) , der fur die Dauer der Servicebeziehung zwischen 
einer Dienstnutzereinrichtung (Client) und einem Application 
Server nicht in diese Beziehung eingebunden ist, (d.h. z.B. 
kein Stateful SIP- Proxy) , ist es fur den Proxy unmoglich eine 

15 zuverlassige Vergebiihrungsf unktion fur registrierte Kunden 
(Anwender und Diensteanbieter) bereitzustellen. 



Bisherige Losungen der Problemstellung 

20 

Proxy bleibt in der Kommunikationsbeziehung fur die Dauer 
der Servicebeziehung (Stateful Proxy) , oder 

Vergebuhrung lauft separat zwischen Application Server und 
Client ohne Einbeziehung des Proxies, d.h. der Betreiber 

25 des Proxies ist ausschlieSlich Access- Provider . Eine Ge- 

samtrechnung aus einer Hand auch fur in Anspruch genommene 
Dienste lassen sich - wenn liberhaupt - dann nur mit grolSem 
Aufwand im Postprocessing erreichen -> Verteilte Billing- 
funktionen beim Proxy-Betreiber und beim Application Ser- 

3 0 ver Provider. Diese Losung erfordert zum einen die Sicher- 

stellung, daiS der Nutzer eines Services auch gleichzeitig 
Kunde von Proxy- und Serverbetreiber ist, und zum anderen 
die Ubermittlung von Daten an den zentralen Rechnung- 
sers teller . 
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Losung der Problemstellung gemaiS der Erfindung 



Die Erfindung beschreibt ein Verfahren, wie in einem derarti- 
gen Scenario mit Client, Proxy (=Applikationsbroker, Applika- 
tionsvermittlungseinrichtung) und Applikat ions server eine fur 
alle Partner zuverlassige Vergebuhrung erreicht werden kann, 
die zudem fur den Anbieter (Provider) des Grunddienstes 
(Betreiber des Proxy) einen Mehirwertdienst darstellt. Dieser 
Provider ist damit in der Lage, seinem Endkunden eine zuver- 
lassige Rechnung aus einer Hand mit paketorientierten Diens- 
ten von unterschiedlichsten Partner- Serviceprovidern anzubie- 
ten. Dabei kann der Grunddienstanbieter sowohl als einfacher 
Vermittler eines Dienstes, als auch als Zwischenhandler mit 
,,Rebranding^^ auftreten (Unter „Rebranding^^ wird hierbei ver- 
standen, dass der Betreiber des Proxy einen Dienst eines 
Partner -Serviceprovider nicht unter dem ursprunglichen Namen 
des Dienstes sondern unter einem eigenen Produktnamen anbie- 
tet) . 

Letztendlich ist der Zweck dieses Verfahren^ 

a) Registrierten Endkunden (Clients) mit einem Guthabenkon- 
to in Echtzeit Nutzungsgebuhren fur angeforderte und ge- 
nutzte Dienst e zu verrechnen, oder 

b) Registrierten Endkunden regelmaSig (z.B. monatlich) eine 
einheitliche Gesamtrechnung fur alle genutzten Services 
von unter schiedlichen Providern zu erstellen. 

Mit dem Verfahren wird sichergestellt , dass 

a) der Kunde nur das bezahlt, was er nutzt, und 

b) der Diensterbringer fur seine Leistungen bezahlt wird* 

Daneben schafft dieses Verfahren die Voraussetzung dafiir, daS 
dem Kunden als Option schon wahrend der Dienstenutzung in Re- 
al zeit angezeigt werden kann, welche Gebuhren fur den Dienst 
aufgelaufen sind, bzw. bei Prepaid- Service, wie viel Guthaben 
noch vorhanden ist . 
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Grundlage dieser Losung ist eine zuverlassige Vergebuhrungs- 
funktion, in die alle Partner -Komponent en (Client, Proxy / 
Application Broker, Application Server) _ wahrend der Dienste- 
nutzung eingebunden sind. 

5 

Client : Authentif iziert sich beim Proxy und fordert Dienst 
an. 

Proxy / Application Broker : Vermittelt Dienst und fuhrt Buch 
iiber die Nutzung dieses Dienstes durch den Client - 
10 Application Server: Bietet Dienst an und infoarmiert mit Ti- 
ckets den Proxy iiber Zustandekommen und Verlauf der Service- 
beziehung zwischen ihm und dem Client* 

Abbildung 1 beschreibt bei einer Realisierungsvariante der 
15 Erfindung die Beziehungen der Partner -Komponent en untereinan- 
der und den prinzipiellen Ablauf von der Authentif izierung 
des Clients uber die Dienstanf orderung und Diensterbringung 
bis bin zur Vergebuhrung . 

- Nachdem sich der Client mithilfe des Proxy bei dem Authen- 

20 t i f icat ion-Authori zat ion-Account ing- Server (AAA- Seirver ) 

authentif iziert hat (l)/(2) erhalt er von dem Proxy zusam- 
men mit der Angabe, wo sich der Application Server befin- 
det (Destination) eine Billing-Reference (pi) , die vom 
Proxy zur Ausubung der Vergebuhrungsf unktion fur die an- 

25 stehende Dienstnutzung generiert wird (3) . 

Der Client fordert mit der Information, die er vom Proxy 
erhalten hat, beim Application Server den gewiinschten 
Dienst an (4) . Dieser bestatigt die Dienstanf orderung an 
den Client (5) . Hiermit ist die Servicebeziehung zwischen 

30 Client und Application Server eingerichtet . 

Nachdem die Servicebeziehung zwischen Client und Applica- 
tion Server aufgebaut worden ist, und solange der Dienst 
genutzt wird, erstellt der Application Server in regelma- 
fiigen Abstanden (z.B. 1 pro Minute) Tickets, die an die 

35 Vergebiihrungsfunktion auf dem Proxy gesendet werden (6) . 

Diese Tickets enthalten die Reference pi, die dem Proxy 
erlaubt, effizient auf die Vergebuhrungstabelle (Billing- 
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Tabelle) zuzugreifen. und die Reference si, die der Server 
selbst erstellt hat, und mit welcher er gegebenenf alls 
spater bei einer Ruckmeldung vom Proxy effizient auf seine 
Daten zugreifen und eine bestehende Service Relationship 
beenden kann. 

Nach Erhalt eines Tickets (6) ermittelt der Proxy anhand 
der in dem Ticket enthaltenen Reference pi den Client (IP- 
Adresse CI) und fordert von diesem fur jedes etnpfangene 
Ticket eine Bestatigung dieser Vergebuhrvmgsdaten an (7) . 
Falls nach einer bestimmten Zeit (z.B. 1 Sekunde) die Bes- 
tatigung nicht empfangen wurde, wird die Anforderung (7) 
ein- Oder zweiraal wiederholt. 

- Nach Empfang der Bestatigungsanf orderung verifiziert der 
Client das Ticket und sendet gegebenenf alls eine Bestati- 

15 gung an den Proxy (8) . 

- Nach Empfang einer Bestatigung vom Client speichert der 
Proxy das Ticket zu einer spateren Rechnungserstellung ab 
(9) und informiert den Server, dass der Client das Ticket 
bestatigt hat. Im Falle eines Prepaid- Kunden aktualisiert 
die vergebiihrungsfunktion auf dem Proxy den Guthabenstand 
des Kunden. 
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Sonderfalle bei der beschriebenen Realis ierungsvariante der 
Erf indung ; 

30 - Prepaid- Kunde : 

Wenn das Guthaben eine bestimmte Schwelle unterschreitet 
informiert der Proxy den Client, daS das Guthaben fast 
aufgebraucht ist. Dies kann z.B. mit der n^chsten Anforde 
rung einer Bestatigung f<ir ein Ticket erfolgen (7) . Falls 

35 das Guthaben aufgebraucht ist, wird der Proxy den Eintrag 

in der Billing Table loschen und weitere Tickets vom Ap- 
plication Server fur diesen Kunden nicht mehr akzeptieren 
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und diese Tickets dem Server negativ quitieren, woraufhin 
dieser die Servicebeziehung zutn Client gegebenenf alls be- 
enden wird. 

5 - Anforderung einer Ticketbestatigung (7) vom Client negativ 
quitiert : 

Der Proxy informiert den Application Server, dass ein Ti- 
cket negativ quittiert wurde, wobei er dem Application 
Server die Reference si zuriickgibt . Anhand der Reference 
10 si ist der Server daraufhin in der Lage, die Servicebezie- 

hung zum Client zu beenden. 

Ticketbestatigung vom Client trotz mehrmaliger Anforderung 
nicht erhalten: 

15 Der Proxy informiert den Application Server, dass er fiir 

ein Ticket keine Quittung vom Client erhalten konnte, wo- 
bei er dem Application Server die Reference si zuriickgibt, 
Anhand der Reference si ist der Server daraufhin in der 
Lage, die Servicebeziehung zum Client zu beenden. 

20 

Timer tl fur Billing Table Eintrag lauft ab. 
Um die Giiltigkeit eines Billig Table Eintrags zu sichern, 
uberwacht der Proxy den Eingang der Tickets vom Server. 
Sobald ein Ticket (6) eintrifft, wird der eingestellte Ti- 
25 mer zuriickgesetzt . Bei Ablauf des Timers wird der Eintrag 

in der Tabelle geloscht • Eventuell nachfolgend eintreffen- 
de Tickets vom Server werden negativ quittiert . 



3 0 Berne rkung en ; 

Zu beachten ist, daS dieses Verfahren nicht erfordert, 
dass Server und/oder Client sich bei Beendigung der Servi- 
cebeziehung beim Proxy abmelden. So erfolgt auch die 
35 Versendung eines Vergebiihrungstickets an den Client immer 

im Voraus fiir das aktuelle Vergebuhrung s interval 1 . Damit 
ist sichergestellt , daS der Client nicht kostenpf lichtige 
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Dienste in Anspruch nimmt, ohne dass er dafur bezahlt, in- 
dem er vor Ablauf eines Vergebuhrungs interval Is einfach 
den Dienst abbricht, urn zu verhindern, dass er fur das 
vergangene Intervall vergebvihrt wird. 

Der Uberwachungstimer tl in der Billing Table muss auf je- 
den Fall groSer als die Lange des Vergebuhrungs intervall 
sein, das zwischen Client und Application Server verein- 
bart wird. Es mu& groS genug gewahlt werden, um zu vermei- 
den, dass eine verloren gegangene (und deshalb vom Server 
wiederholte) Ticketnachricht an den Proxy dazu fiihrt, dass 
dieser den Billing Table Eintrag fiir ungultig erklart . 
Gleichzeitig darf tl aber nicbt zu grofi gewahlt werden, um 
zu vermeiden, dass beispielsweise Denial -of -Service Atta- 
cken von boswilligen Clients zu einer Verknappung der Bil- 
ling Table Resourcen und letztlich zu einer Nichtverfiig- 
barkeit dieser Dienste f ^hrt . Ein vemiinf tiger Wert fiir tl 
ist 2-3 Mai die Lange des Vergebuhrungsintervalls . Da die 
Lange der Vergebuhrungsintervalle der einzelnen Servicebe- 
ziehungen (siehe Abb. 1) unterschiedlich sein konnen, wird 
die Lange des Uberwachungstimer tl variabel gestaltet . So- 
bald der Proxy ein Ticket vom Server erhalt, verwendet er 
die darin angegebene Lange des Vergebuhrungs intervall und 
bestimmt daraus die Lange von tl, um den Empfang des 
nachsten Tickets vom Server fur diese Servicebeziehung zu 
uberwachen. Bis zum Empfang des ersten Tickets vom Server 
wird ein fur die Billing Table einheitlicher fester Initi- 
alwert fur diesen Timer verwendet (z.B. 5 Sekunden) . 
Mogliche vertrauensbildende MaSnahmen zwischen Client und 
Application Server: Die Konditionen fiir die Servicebezie- 
hung (Lange und Kosten des 1. Intervals, Lange und Kosten 
der Folgeintervalle) werden zwischen Client und Server 
vereinbart. Durch die Wahl eines kurzen 1. Intervals und 
ggf . Sonderkonditionen dafiir kann sichergestellt werden, 
daS auch im Falle einer Nichterbringung der Leistung (z.B. 
Serverausfall, SW-Fehler, Inkompatibilitat von Client und 
Serversoftware) trotz aufgebauter Servicebeziehung fiir den 
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Dienstanwender kein oder nur ein geringer Nachteil ent- 
steht • 

- Bei Ausfall der Vergebiihrungsf unktion des Proxies kann der 
Application Seirver aufgrund der ausbleibenden Quittung auf 
das Ticket die Servicebeziehung zum Client gegebenenf alls 
abbrechen . 

- Bei Ausfall des Clients wird das Gebiihrenkonto des Kunden 
nicht f alschlicherweise weiter vom Server belastet, da 
Client nicht mehr in der Lage ist, weitere Ticketbestati- 
gungsanforderungen des Proxy zu quittieren (siehe Sonder- 
falle) . 

Punktionalitat beim Client erweiterbar z.B. um 
i. Kummulierung der vom Proxy ubermittelten Gebuhrennach- 
richten und Anzeige dieser Gebuhren am Terminal zur Ge- 
biihren-uberwachung in Realzeit. 
ii. Moglichkeit fur Endbenutzer als Option Tickets manuell 
zuriickzuweisen, z.B. bei Erreichen eines bestimmten 
selbstgesetzten Gebuhrenlimits . 

Zusammenf assend kann folgendes gesagt werden. Das beschriebe- 
ne Verfahren erlaubt dem Betreiber eines Stateless Proxy bzw. 
Application Brokers auf einfache Art und Weise registrierten 
Application Service Anbietern und registrierten Kunden eine 
zuverlassige, in def inierbaren Intervallen genaue und ver- 
trauenswurdige Vergebiihrungsf unktion anzubieten, indem sich 
wahrend der Diensterbringung Client und Server standig im 
Hintergrund in regelmaJSigen Abstanden liber einen unabhangigen 
Dritten (Proxy) liber die dafur anfallenden Gebuhren verstan- 
digen und die Vergebiihrungsf unktion auch von dem unabhangigen 
Dritten erbracht wird. 



Anwendungsbeispiele der Erfindunc? 



- Auskunf tsdienste 



- Videodienste 

- Telefonzusatzdienste, wie z.B. Konferenzen iiber Konferenz- 
server 

- Mailboxabfragen 

anonymes Billing fur Gateways, die aus dem offenen Inter- 
net angesteuert werden 
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1. Dienstvermittlungseinrichtung, die 

a) von einem Client eine Dienstanf orderung empfangt, 

b) daraufhin eine Authentif izierung durchfuhrt und dem Client 
nach einer erf olgreichen Authentif izierung eine Reference 
auf einen Application Server zur Durchfuhrung des angefor- 
derten Dienstes mitteilt, 

c) von dem Application Server erstellte Vergebuhrungs tickets 
empfangt, wobei die Tickets Inf ormationen hinsichtich der 
vor bzw. wahrend der Dienstnutzung anfallenden Gebiihren 
enthalten, 

d) bezilglich eines empfangenen Tickets jeweils eine Bestati- 
gungsanfrage an den Client richtet, 

e) fiir das Ticket einer Gebiihrenregistrierungsaktion durch- 
fuhrt, falls der Client das Ticket bestatigt. 

2. Dienstvermittlungseinrichtung nach Anspruch 1 
dadur ch gekennze i chne t , 

dass die genannte Gebiihrenregistrierungsaktion darin besteht, 
dass die Dienstvermittlungseinrichtung den Guthabenstand oder 
Gebuhrenstand des Client aktualisiert . 

3 . Dienstvermittlungseinrichtung nach Anspruch 1 
25 dadurch gekennze i chne t, 

dass die genannte Gebiihrenregistrierungsaktion darin besteht, 
dass sie das Ticket zu einer spateren Rechungserstellung ab-' 



speichert . 

4. Dienstvermittlungseinrichtung nach einem der Anspriiche 1 
bis 3 , 

dadurch gekennzeichnet, 

dass sie dem Client die fiir die Gebiihrenregistrierungsaktion 
herangezogene Gebiihr mitteilt. 
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^ Aoolication Server, der ^ 
von einem Client eine Dienstanf orderung .^t^t. wobe. 
Z Oienetanforderung eine Reference auf eine nienstver-. 
mif tlunqseinrichtung enthalt, 
v>, bezlg^ch dee Dienstes vergebuhrungs-TiOcetB erstellt und 
diese an die Dienstvem-ittlungeeinricbtung sendet wenn er 
den service-Request anni^nt, «obei die Tickets Informatxo- 
nen hfnsichtich der vor bzw. w»i>rend der DurchfOhrung des 
plenstes «r den Client f.llig werdenden Geb<ihren enthal- 

c, ton der Dienstvermittlungseinrlchtung Mitteilungen daruber 
' :::«:gt. die Ti^et. dur^ den Client best^tigt „er- 

d) die' Durch£uhrung des DiensteB aufrecKterbMt. solange die 
Tickets durch den Client poeitiv bestatigt werdan. 

6 . Application Server nach Anspruch S , 

daduroh gekennzeichnet, beendet, wenn er von 

dass er die servicebeziehung zum Client beenae 

,-Hn,maseinriohtung die Mitteilung empfangt, 
der Dienstvermittlvmgsemricntu a Ti- 

dass der Client eine Best&tigungsanlrage bazuglroh exnae Ti 
okets negativ quittlert hat. 

7 Application server nach Anspruch 5, 

TsTr l^irbr^Iehung .u. Client beendet. .enn er von 

re:^ienstver.ittlung3einr™^^^^^^^ 

dass der Client eine Bestatigungsanrrage w . 

TigLgsanfragen bez<lglich eines Tickets <iberhaupt n.cht gurt- 

) tiert hat. 

8. Application Server nach Anspruch 5, 

dadurch gekennzeichnet beendet, wenn er von 

dass er die Servicebezxehung zum Clxent oeena 
dass er • ^^aseinrichtung iiberhaupt keine Quittung 

der Dienstvermxttlungseinri(-.iii-"iAa ^ 

auf das von ihm generierte Ticket erhalt . 



5 



10 



200319294 



9. Application Server nach Anspruch 5, 
dadurch gekennzeichnet , 

dass er die Servicebeziehung zum Client beendet, wenn er von 
der Dienstvermittlungseinrichtung im Falle eines Prepaid- 
5 Nutzers beziiglich eines Tickets die Mitteilung erhalt, dass 
kein ausreichendes Guthaben mehr vorhanden ist . 

10. Client, der 

a) an eine Dienstvermittlungseinrichtung eine Dienstanf orde- 
10 rung stellt, 

b) nach einer erf olgreichen Authentif izierung der Dienstan- 
forderung von der Dienstvermittlungseinrichtung eine Refe- 
rence auf den angef orderten Dienst empfangt, 

c) anhand der genannten Reference eine Servicebeziehung zu 
15 einem Application Server des angef orderten Dienst es auf- 

baut / 

d) von der Dienstvermittlungseinrichtung Bestatigungsanf ragen 
beziiglich des Dienstes fallig werdender Gebiihren empfangt, 

e) die genannten Bestatigungsanf ragen gegeniiber der Dienst- 
20 vermittlungseinrichtung verifiziert und beanwortet. 

11. Client nach Anspruch 10, 
dadurch gekennzeichnet , 

dass er die von der Dienstvermittlungseinrichtung mithilfe 
25 der Bestatigungsanf ragen libermittelten Gebiihrennachrichten 

kumuliert und diese Gebiihren dem Endnutzer zur Gebiihr enuber - 
wachung in Realzeit anzeigt . 

12. Client nach Anspruch 10 oder 11, 
3 0 dadurch gekennzeichnet , 

dass er es dem Endbenutzer erlaubt, eine Gebuhrennachricht 
manuell zu beantworten. 

13. Verfahren zur Vergebuhrung eines Dienstes in einem Kommu- 
35 nikationsnetz , demgemaS 

f) von einem Client an eine Dienstvermittlungseinrichtung ei- 
ne Dienstanf orderung gestellt wird. 
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■ -thilfe der Dienstvermittlungseinr.chtung exne 
g) daraufhxn ^^.^ ,ird, wobei dem Client von 

Authentif izierung durchgeEunr erf olgreichen 

der -ens.ver.i.tlungseln..^^^^^^^^ 
Authentif izierung exne Dxenst Re 

derten Dienst tnitgetexlt wxr , oienst-Ref erence eine 

riient anhand der genannten Dien&u 
h) von dem Client ann Application Server des angefor 

Servicebeziehung zu einem Appx 

derten Dienstes ^^^^^^"^ 3^^^, eine Reference auf 

von de. Client de. ^^^^^^^^^^^ ,,,,, 

die 'n,::^ Ticlcets erstellt und an die 

3) von denv ^^^^^^^^^^^^ gesendet werden, wobei die 

Dienstvermittlungseinr , .^.^t. ^er vor bzw. wahrend 

.ICete entbalten, 
der Dienstnutzung ^^^^^^^f^^^ bezaglicb eines Ti- 

K) von der ^-"-^^^^""^""f,";" an den Client gerichtet 
ckets eine Bestatigungsanf rage an 

bestatigt wird, von der Dienstvermitt- 
1) falls das Txcket fl^^^^J ^.^^^ Gebubrenregistrxe- 

lungseinrichtung das TicKet z 
rungsaktion herangezogen wxrd. 

14 . verf ahren nach Anspruch 13 , 
dadurch gekennzeichnet. 

dass . von der Dienstver- 

^ • « /»o-r- Bestatigungsanf rage von 

S a) das ^-9*"^^L^f^;,^;'^ Ln ^application server weiterge- 
mittlungsexnrxcncung 

leitet wird, dienstes seitens des Application Ser 

b) die Durcbfahrung des Dxenst Tickets durch den 

vers aufrecbterhalten wxrd, solange ax 

... i_ 4-!i+--if-Tt- werden. 
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Kf^Qt-atigt werden. 
Client posxtxv t)est:ai:.ia>- 
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Zusammenf assung 



Verfahren zur Vergebuhrung eines Dienstes in einem Kommunika- 
tionsnetz 

5 

Das beschriebene Verfahren erlaubt dem Betreiber eines State- 
less Proxy bzw. Application Brokers auf einfache Art und Wei- 
se registrierten Application Service Anbietern und regist- 
rierten Kunden eine zuverlassige, in def inierbaren Interval - 

10 len genaue und vertrauenswiirdige Vergebuhrungsf unktion anzu- 
bieten, indem sich wahrend der Diensterbringung Client und 
Server standig im Hintergrund in regelmaSigen Abstanden liber 
einen unabhangigen Dritten (Proxy) liber die dafiir anfallenden 
Gebuhren verstandigen und die Vergebuhrungsf unktion auch von 

15 dem unabhangigen Dritten erbracht wird. 



Figur 1 
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